The present disclosure relates generally to logical validation and, more particularly, to performing logical validation on loaded data.
During the life cycle of application software, there may be situations in which data object collections are obtained in advance of performing logical validation (e.g., inputs or updates in applications at the logical level, loads, batch loads, data migration from customers, and data loads from testers for large data volumes). Currently, the alignment is achieved manually or by using in-house tools.
In one application, each visitor to a website may be subject to different validation logic for a business object. For example, in a shopping website, a first developer may require a bid that is input from a buyer to be higher than a reserve price of a commodity, while a second developer may require a model of a commodity that is input from a seller to be a known model. FIG. 2 is a schematic diagram showing mapping relations between business objects in an application and data objects in a database. One business object may relate to a plurality of columns in a plurality of tables in the database. As can be seen from FIG. 2, the business object is mapped to a table Object_1_Table of the data object in the database. Columns in the table are taken from actual data tables Element_1_table, Element_2_table, Element_3_table, etc., in the database respectively, and logical validation from different developers may relate to different columns in Object_1_Table. For example, logical validation from a first developer relates to an Attr_1 column of Element_1_table and an Attr_2 column of Element_2_table, logical validation from a second developer relates to the Attr_1 column of Element_1_table, the Attr_2 column of Element_2_table and an Attr_3 column of Element_3_table, and logical validation from a third developer relates to the Attr_1 column of Element_1_table, the Attr_3 column of Element_3_table and an Attr_4 column of Element_3_table.
Currently, when validation rules are changed (for example, additions or updates to validation rules), new validation rules are used to perform re-validation on data in the database. Such re-validation is performed for the whole data object table. Furthermore, when batch load, database migration or SQL insert/update occurs, it is necessary to perform logical validation on newly inserted or updated data.
Batch loaded data usually is typically used for business logical validation. In logical validation, the application is taken offline to perform the logical validation on batch loaded data in the background. Thus, completing logical validation after new data or new rules are added (such that the application can be returned to its online state) is a time-consuming process.